home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-houttuin-mailservers-00.txt
< prev
next >
Wrap
Text File
|
1993-03-03
|
27KB
|
873 lines
Mail Requirements Group Jeroen Houttuin
INTERNET-DRAFT Allan Cargille
September 1992
Requirements for mail based servers
Abstract
This document defines minimal requirements and
recommendations that must be implemented in all mail based
servers in the Internet e-mail community and all e-mail
networks connected to it, such as the GO-MHS community.
Status of this Memo
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of
six months. Internet Drafts may be updated, replaced, or
obsoleted by other documents at any time. It is not
appropriate to use Internet Drafts as reference material
or to cite them other than as a "working draft" or "work
in progress."
Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of
this or any other Internet Draft.
Distribution of this memo is unlimited.
INTERNET-DRAFT September 1992
Contents
1. Introduction 1
2. Terminology 3
3. Mail based server types 4
3.1. Replier 5
3.1.1. Echo server 5
3.1.2. (NON)-Delivery Message 5
3.1.3. Command server 5
3.1.4. Auto-replier 5
3.2. Forwarder 6
3.2.1. Distribution List 6
3.2.2. Auto-forwarder 6
4. Requirements 6
4.1. General 7
4.2. Repliers 7
4.2.1. Echo-servers 8
4.2.2. (NON)-Delivery Messages 9
4.2.3. Command servers 9
4.3. Forwarders 10
4.3.1. Distribution Lists 10
4.3.2. Auto-forwarders 10
5. Recommendations 10
5.1. General 10
5.2. Repliers 11
5.2.1. Echo-servers 11
5.2.2. Command servers 11
5.3. Forwarders 12
5.3.1. Distribution Lists 12
5.3.2. Auto-forwarders 12
6. Mapping to X.400(88) and RFC 822 12
7. Acknowledgements 13
8. References 13
9. Authors' Addresses 14
1. Introduction
Electronic mail systems are increasingly being used by
automated processes, such as echo servers, distribution
lists, etc. Although such applications differ widely in
nature, they have many properties and problem areas in
common and can be grouped under the term 'mail based
servers'.
Mail based servers are used for a number of purposes:
- Enhancing the Message Handling Environment. Examples
of such usage are distribution lists (DLs) and mail
based file servers.
Houttuin, Cargille Expires: April 1993 [page 1]
INTERNET-DRAFT September 1992
- Monitoring the status of the MHS. Examples of this
usage are echo servers and forced (non-)delivery
messages (the so-called nosuchuser test).
Since mail based servers deal with automatically
receiving, forwarding and replying to messages, which may
themselves have been generated by automatic processes,
strong requirements are needed on the one hand to minimise
human effort to manage such servers, and on the other hand
to make the behaviour of mail based servers deterministic
enough to build reliable tools upon them.
A classic example of what can go wrong is when a DL
contains an invalid address. The remote mailer generates a
non-delivery message and sends it to the originator of the
original message, which, under circumstances, could be the
DL itself, which then again distributes the non-delivery
message to the non-existing recipient, etc. Following
strict requirements on how a DL should handle message
header fields will avoid such looping-endangered
situations.
A more complicated example of the usefulness of strong
requirements for mail based servers is the following:
suppose a distributed tool will check the connectivity of
mailers by sending a message to an echo-server. The
connectivity tool could request the echo to be sent to
another component of the tool instead of to itself. If for
some reason the address of that other component cannot be
routed to, an automatically generated non-delivery message
could be sent back to the echo server, which results in a
message loop.
Throughout this document, X.400(84) terminology is
preferred to X.400(88) and RFC 822 for the following
reasons
- X.400 has more pre-defined message attributes than
RFC 822
- X.400(88) has already defined a specific mechanism
for DLs. This implies that a separate recommendation
for a mail based server approach to DLs is only
useful in the context of X.400(84) or RFC 822.
- Requirements for mail based servers are needed now.
Since most available products are X.400(84)
implementations, this document will sort more effect
if it uses X.400(84) terminology.
Once expressed in X.400(84) terminology, most requirements
can be mapped to RFC 822 and X.400(88) mail systems using
Houttuin, Cargille Expires: April 1993 [page 2]
INTERNET-DRAFT September 1992
RFC 1327 and X.400(84) to X.400(88) upgrading,
respectively. For the reader's convenience, chapter 6
lists the used X.400(84) terminology together with their
RFC 822 and X.400(88) equivalents. For those requirements
that cannot be mapped implicitly, chapter 6 will also
explicitly state how such requirements must be implemented
for the other mail standards.
The requirements defined in this document will as much as
possible be aligned with comparable rules that either have
already been defined in other standards (X.400(88) DLs) or
have already been used for a long time (X.400(84) Status
Reports; distribution lists in the Internet).
2. Terminology
Mail based server (MBS)
A mail based server is a process in an MHS that
automatically generates (a) message(s) as a result of
receiving a message. An MBS can be implemented/modelled in
the following ways:
- within the MTS, in which case it can be considered an
enhancement of the X.400 message dispatcher. This is
called a P1 MBS.
- as an MTS service user, in which case it can be
considered an automated User Agent (UA). Per default,
this is called a P3 MBS. If, in addition, the MBS is
P2 based, it is called a P2 MBS.
Upon receiving a message, an MBS will generate at least
one message, whose contents and list of recipients depend
on
- the kind of server
- the contents and header of the received message.
(Non-)Dedicated MBS
A dedicated MBS is an MBS that is meant to be used as an
MBS only. Examples of non-dedicated MBSs are auto-
forwarding UAs, and UAs that automatically send back
vacation notes (auto-repliers).
Houttuin, Cargille Expires: April 1993 [page 3]
INTERNET-DRAFT September 1992
MBS administrator
For every dedicated MBS, there exists an MBS administrator
who is responsible for managing the MBS.
MBS Submit Permission
Associated with an MBS is a list of addresses that are
allowed to use the MBS (I.e. have the MBS send output
messages). Implementation of MBS Submit Permission is
considered a local matter. The main implementation options
are:
- Implicit: Only those addresses explicitly listed are
not allowed to send messages to the MBS.
- Explicit: Only those addresses explicitly listed are
allowed to send messages to the MBS.
Messages
An input message is a message that triggers the generation
of (a) message(s) by an MBS. Depending on the
implementation of the MBS, this is defined either as a
P1.MPDU or as the parameters of an MTS.DELIVER.Indication.
An output message is a message that is being generated by
an MBS as a result of a received input message. Depending
on the implementation of the MBS, this is defined either
as a P1.MPDU or as the parameters of an
MTS.SUBMIT.Request.
Originator
For P2 messages, the originator of an input message is
defined as the P2.originator, or if this attribute is not
present, the P2.authorizingUsers. For non-P2 messages, the
originator of an input message is defined as the
P1.originator.
3. Mail based server types
This chapter defines the different types of MBSs. Two main
types are identified: repliers and forwarders.
Houttuin, Cargille Expires: April 1993 [page 4]
INTERNET-DRAFT September 1992
3.1. Replier
Intuitively speaking, a replier is an MBS that will send
an output message to the originator of the input message.
There are also exceptions to this rule, such as replying
to a P2.replyToUsers field. More formally speaking, a
replier is characterised by the fact that the recipient of
the output message is uniquely defined in (the heading of)
the input message. The different types of repliers can be
classified by the content of the output message.
3.1.1. Echo server
An echo server is a dedicated replier that will submit the
contents of the input message.
3.1.2. (NON)-Delivery Message
This document does not consider the behaviour of
P1.Service.MPDUs and P2.SR-UAPDUs, which is assumed to be
well defined in X.400(84) already. RFC 822 mailers and
RFC 1327 gateways however can generate a message (P2.IM-
UAPDU) explaining the (NON-)Delivery of an input message.
In this case the mailer/gateway can be considered an MBS.
The MBS administrator is the administrator of the
mailer/gateway.
3.1.3. Command server
The contents of an output message submitted by a command
server depends on commands that were included in the input
message. Concrete examples are file servers, archie
servers, DL-registration servers and address conversion
servers.
3.1.4. Auto-replier
Some UAs have an auto-reply feature that will temporarily
and/or conditionally turn the UA into an MBS. Thus an auto-
replier is a non-dedicated replier. The content of the
output message is often a note such as 'I am on holidays.'
Houttuin, Cargille Expires: April 1993 [page 5]
INTERNET-DRAFT September 1992
3.2. Forwarder
A forwarder is an MBS that will send its output messages
to a list of recipients. These recipients are independent
of (the heading of) the input message.
3.2.1. Distribution List
Upon receiving an input message, a DL will generate output
messages to a list of DL members, which is managed by the
MBS administrator.
In X.400(84), no DLs are defined. Many vendor-specific
implementations exist, some of which are nothing more than
local multi-recipient aliases, others use local
directories for DL expansion. This document defines the
requirements for X.400(84) DLs as well as a recommendation
for how to implement them. Their behaviour will as much as
possible be aligned with that of X.400(88) DLs.
3.2.2. Auto-forwarder
Some UAs have an auto-forward feature that will
temporarily and/or conditionally turn the UA into an MBS.
Thus an auto-forwarder can be considered a non-dedicated
forwarder. Upon receiving an input message, an auto-
forwarder will submit an output message to a locally
defined (list of) address(es), which is managed by the
owner of the UA.
4. Requirements
MBSs shall follow the requirements defined in X.411 and
X.420 as a minimum. This document describes additional
requirements in terms of P1, P3, and P2. Depending on the
implementation of the MBS, it can discard requirements
that are not applicable. I.e.: as far as appropriate, any
P2 MBS shall not only follow the P2 requirements, but also
all P3 requirements, and any P3 MBS shall also follow all
P1 requirements.
Houttuin, Cargille Expires: April 1993 [page 6]
INTERNET-DRAFT September 1992
4.1. General
- The following attributes shall have the same value in
the output message as in the input message:
P2.Sensitivity
- I case of an MBS Submit Permission violation, a
P1.DeliveryReportMPDU shall be sent to the
P1.originator of the input message. The
P1.DeliveryReportMPDU shall have the following
values:
ReasonCode: unableToTransfer(1)
DiagnosticCode: uaUnavailable(4)
SupplementaryInformation: "Submit Permission Violation"
- The address of the MBS administrator shall be the
same as that of the MBS, except for the Personal
Name.
- The following types of input messages are invalid as
input messages:
P1.ServiceMPDU
P2.SR-UAPDU
Instead of generating an output message, the MBS
shall send a warning message to the MBS
administrator.
4.2. Repliers
- The following attributes shall have the same value in
the output message as in the input message:
P3.Priority
P2.Importance
- The following attributes shall not be used in the
output message:
P2.replyRequest
Houttuin, Cargille Expires: April 1993 [page 7]
INTERNET-DRAFT September 1992
P2.replyBy
P2.expiryDate.
- If a P2.replyToUsers field is used in the output
message, it shall not contain the address of the MBS.
- Repliers shall not send output messages to addresses
which are likely to be MBSs, such as addresses with
the following values in the Surname attribute:
echo
autoanswer
listserv
netserv
These values must be matched in any combination of
upper case and lower case. Instead, a replier shall
forward the input message to the MBS administrator.
The list of dangerous Surnames is subject to change;
an up-to-date version of this list is available in
[dontreply]
- Every PerRececipientFlag in the output message shall
have the following bits set:
Report Request: 00
User Report Request: 00
i.e. the Non-delivery Notification service shall be
prevented.
4.2.1. Echo-servers
- The following attributes shall have the same value in
the output message as in the input message:
P1.ContentType
- If a P2.replyToUsers field is present in the input
message, the output message shall be sent to this
address. Otherwise the output message shall be sent
to the originator of the input message. If the
P2.replyToUsers field contains more than one address,
Houttuin, Cargille Expires: April 1993 [page 8]
INTERNET-DRAFT September 1992
at least the first address shall be replied to.
Replying to the others is not recommended.
- If an output message is not sent to the P2.originator
of the input message, its P2.authorizingUsers field
shall contain the addresses of the P2.originator and
the P2.authorizingUsers of the input message.
- The P2.originator of the output message shall contain
the address of the MBS administrator.
- Echo servers shall not send an output message if the
input message contains a P2.In-Reply-To or
P2.crossReferences field. Instead, the input message
is forwarded to the MBS administrator.
4.2.2. (NON)-Delivery Messages
- The P1.recipient and the P2.recipient of a (non-)DM
should equal the P1.originator of the input message.
- A message addressed to S=nosuchuser should always
result in an NRN or a non-DM being generated.
- The P2.Originator of the output message shall contain
the address of the MBS administrator.
4.2.3. Command servers
- If a P2.replyToUsers field is present in the input
message, the output message shall be sent to this
address. Otherwise the output message shall be sent
to the originator of the input message. If the
P2.replyToUsers field contains more than one address,
at least the first address shall be replied to.
Replying to the others is not recommended.
- If an output message is not sent to the P2.originator
of the input message, its P2.authorizingUsers field
shall contain the addresses of the P2.originator and
the P2.authorizingUsers of the input message.
- The P2.Originator of the output message shall contain
the address of the MBS administrator.
- Command servers shall not send an output message if
the input message contains an P2.inReplyTo or
P2.crossReferences field. Instead, the input message
Houttuin, Cargille Expires: April 1993 [page 9]
INTERNET-DRAFT September 1992
is forwarded to the MBS administrator.
4.3. Forwarders
- The following attributes shall have the same value in
the output message as in the input message:
P3.ContentType
4.3.1. Distribution Lists
- The P1.contents of an output message shall be the
same as that of the input message.
- The P1.originator of the output message shall contain
the address of the DL administrator.
- All P1.ExtensionIdentifiers in an output message
shall be distinct.
4.3.2. Auto-forwarders
- The output message(s) shall have the P2.autoForwarded
flag set to true.
5. Recommendations
Please note that all recommendations for names of MBSs and
MBS administrators should apply to internationally used
MBSs. Local MBSs can use similar mechanisms in their local
language.
5.1. Generals
- For all MBSs, at least an MBS administrator with
Surname=postmaster should exist.
- MBS Submit Permission implementation should be
'implicit'.
Houttuin, Cargille Expires: April 1993 [page 10]
INTERNET-DRAFT September 1992
5.2. Repliers
- The P2.In-Reply-To attribute of an output message
should contain the IPMessageID of the input message.
- A replier should not reply to an auto-forwarded input
message.
- Dedicated repliers should at least log the
P2.Originator of the input message and the
P2.recipient of the output message so that the MBS
administrator can track down malicious behaviour.
- The P2.inReplyTo and P2.crossReferences attributes
are optional in an output message. If used, they
should contain the IPMessageID of the input message.
5.2.1. Echo-servers
- The Surname attribute of the echo server should have
the value "echo".
- The Surname attribute of the echo server
administrator should have the value "echo-reply".
- The complete input message should be included in the
output message in a readable format, e.g. in an
IA5Text bodypart.
- The P2.subject of the output message should contain
the string 'Re: ', concatenated with the subject of
the input message.
- An echo server may put additional information in
separate bodyparts.
5.2.2. Command servers
Although it is beyond the scope of this document to define
requirements for the command syntax used by command
servers, it is in general recommended that:
- Commands should only be put in the body of the input
message, e.g. a command server should ignore the
P2.subject field.
- It is recommended that the recipient of the output
Houttuin, Cargille Expires: April 1993 [page 11]
INTERNET-DRAFT September 1992
message can be uniquely identified from the heading
of the input message. I.e. Alternate recipients
should not be negotiated in the body of the input
message.
5.3. Forwarders
5.3.1. Distribution Lists
- DLs should preferably be implemented as P1 MBSs. This
has some important advantages over P3/P2 based
implementations:
- Using P3 would result in loosing
P1.TraceInformation
- Better alignment with X.400(88), which also
defines DLs within the MTS
- An MTS DL distributes P1.UMPDUContent
transparently, and will thus implicitly
implement one of the requirements for DLs.
- The Surname attribute of the DL administrator should
be that of the DL, concatenated with "-request".
5.3.2. Auto-forwarders
- The input message should be encoded as a
P2.ForwardedIPMessage bodypart in the output message.
6. Mapping to X.400(88) and RFC 822
For the exact mapping between X.400 and RFC 822, see RFC
1327. The following table gives some examples:
X.400(84) X.400(88) RFC 822
----------------------------------------------------------
P2.expiryDate IPMS.Heading.expiry-time Expiry-Date:
P2.inReplyTo IPMS.Heading.replied-to-IPM In-Reply-To:
P2.replyBy IPMS.Heading.reply-time Reply-By:
P2.replyToUsers IPMS.Heading.reply-recipients Reply-To:
etc.
Houttuin, Cargille Expires: April 1993 [page 12]
INTERNET-DRAFT September 1992
88 based DLs shall, in case of conflicts between the
requirements stated in this document and those in
X.400(88), follow the requirements in X.400(88).
7. Acknowledgements
Within the context of the connectivity testing tool
'concord', initial work on the requirements for echo
servers and distribution lists was done within COSINE MHS
and XNREN (see [Concordreqs]).
Thanks for comments and corrections: Urs Eppenberger
(SWITCH), Juan Pizzorno (DFN).
8. References
CCITT/ISO88a.
CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1,"
Message Handling: System and Service Overview , December
8.1.
CCITT/ISO88b.
CCITT/ISO, "CCITT Recommendations X.420/ ISO IS 10021-7,"
Message Handling Systems: Interpersonal Messaging System,
December 1988.
CCITT/ISO88c.
CCITT/ISO, "CCITT Recommendations X.411/ ISO IS 10021-4,"
Message Handling Systems: Message Transfer System: Abstract
Service Definition and Procedures, December 1988.
CCITT/ISO88d.
CCITT/ISO, "Specification of Abstract Syntax Notation One
(ASN.1)," CCITT Recommendation X.208 / ISO IS 8824, December
8.2.
Concordreqs.
COSINE MHS server
Mail: cosine-mhs-server@nic.switch.ch
FTP: nic.switch.ch, Username: cosine
File: procedures/echo-server-reqs
Crocker82.
Crocker, D., "Standard of the Format of ARPA Internet Text
Messages," RFC 822, UDEL, August 1982.
Houttuin, Cargille Expires: April 1993 [page 13]
INTERNET-DRAFT September 1992
Dontreply.
COSINE MHS server
Mail: cosine-mhs-server@nic.switch.ch
FTP: nic.switch.ch, Username: cosine
File: procedures/dontreply
Hardcastle-Kille92a.
Hardcastle-Kille, S., "Mapping between X.400(1988) /
ISO 10021 and RFC 822," RFC 1327, UCL, May 1992.
Hardcastle-Kille92b.
Hardcastle-Kille, S., "X.400 1988 to 1984 downgrading," RFC
8.3. UCL, May 1992.
Kille-86.
Kille, S., "Mapping between X.400 and RFC 822," RFC 987,
June 1986.
Westine/Postel91.
Westine, A. & Postel, J., "Problems with the Maintenance
of Large Mailing Lists," RFC 1211, March 1991.
9. Authors' Addresses
Jeroen Houttuin Allan Cargille
TOP LEVEL EC University of Wisconsin - Madison
Esserweg 14 1210 West Dayton Street
NL-9722 SN Groningen Madison, WI 53706
Europe USA
Tel. +31 50 255445 Tel. +1 608 262 5084
houttuin@amiga.physik.unizh.ch cargille@cs.wisc.edu
Houttuin, Cargille Expires: April 1993 [page 14]